FIG. 1 illustrates an example of two wireless devices using a “direct mode” of communication, based on the two devices being in relatively close proximity to one another. In an example case, the two devices are referred to as User Equipments, or UEs. Each UE is configured for operation in a Third Generation Partnership Project, 3GPP, communication network, e.g., a cellular communication network based on the Long Term Evolution, LTE, specifications. Further, each device is configured for Device-to-Device, D2D, communications, which allows each device to talk to other devices having compatible D2D communication capabilities. D2D communications may be network-assisted when one or both devices are operating within the coverage of the cellular network.
FIG. 2 illustrates a variation on D2D communications between the two devices. This variation is referred to as “locally-routed” communications, in that the signaling between the two devices is conveyed through a serving base station—eNodeB in LTE. However, unlike conventional cellular communication signaling between two devices, the signaling is not routed through the default path, which includes the “core network” of the supporting cellular communication network. See FIG. 3 for an example of this conventional default-path routing case, where signaling between two UEs is communicated through serving gateway/packet gateway, SGW/PGW, nodes in a Core Network, CN, that is associated with the Radio Access Network, RAN, which is represented by the eNodeBs and supports the two UEs.
In D2D communications, the communication source and the target are wireless devices, e.g., UEs. D2D communication offers a number of advantages, such as offloading of the cellular network, faster communication, increased awareness of surrounding wireless devices of interest, e.g., a given device may be made aware of surrounding devices running the application or applications, higher-quality links due to a shorter distance, etc. Some appealing applications of D2D communications are video streaming, online gaming, media downloading, peer-to-peer, P2P, file sharing, etc.
FIG. 4 illustrates a reference architecture for D2D operations, where “ProSe” denotes “Proximity Services,” and indicates services available via D2D communication between devices in proximity to one another. See the 3GPP Technical Reference, TR 22.803, Feasibility study for Proximity Services, ProSe, for example details regarding this architecture, and the above-described direct communications, locally routed communications, and default-path communications. Further, in the context of FIG. 4, “APP” denotes application, “E-UTRAN” denotes an Evolved Universal Terrestrial Radio Access Network, as used for the radio access part of LTE. “EPC” denotes Evolved Packet Core, as used for the core network part of LTE.
Certain levels of awareness or management of network operations with respect to D2D operations are known. See, for example, WO 2014/163372 A1 to Samsung Electronics Co., Ltd., which interrelates certain network states defined by an Enhanced Packet System, EPS, network, with D2D initiations at a terminal. Further, U.S. Pub. No. 2014/0162643 A1 to Lee discloses a method for executing a D2D communication in a D2D apparatus, such as a terminal. In Lee, the apparatus transmits a server designation request message to a base station, requesting registration as a server terminal, and then transmits D2D-related service information on radio resources allocated by the base station.
However, numerous challenges attend the effective integration of D2D communications capability into the overall communication system framework. For example, it is recognized herein that “Discontinuous Reception” or DRX presents a number of challenges and opportunities with respect to D2D-capable wireless devices. DRX was introduced as a key solution for conserving battery power in wireless devices operating within a wireless communication network.
In the LTE example case, DRX is characterized by the following: DRX is a per UE mechanism, as opposed to being a per radio bearer mechanism; and DRX may be used in RRC_IDLE and RRC_CONNECTED states. In the RRC_CONNECTED state, the eNodeB/UE may initiate the DRX mode when there are no outstanding or new packets to be transmitted or received. In the RRC_IDLE state, 2G and 3G devices use DRX in idle state to increase battery lifetime. Notably, however, the HSPA and LTE standards allow DRX for the connected state. The available DRX values are controlled by the network and start from no DRX up to DRX intervals of x seconds.
Hybrid Automatic Repeat reQuest or HARQ operations related to data transmission are independent of DRX operation, and a given UE or other compatible device wakes up to read the Physical Downlink Control Channel, PDCCH, for possible retransmissions and/or ACK/NAK signaling, regardless of the DRX configuration in use. In the downlink, a timer limits the time a UE remains awake awaiting a retransmission and when DRX is configured, the UE may be further configured with an “on-duration” timer during to control the time the UE monitors the PDCCH(s) for possible allocations.
In a further aspect of DRX, when a UE is configured to use DRX, the UE can send periodic Channel Quality Indicator, CQI, reports back to its supporting network during its “active times”. Radio Resource Control, RRC, operations can further restrict periodic CQI reports, so that they are only sent during the on-duration. An eNodeB does not transmit packets to a UE when the UE is in sleep mode.
DRX during the RRC_CONNECTED mode operation of a UE should not be confused with DRX during IDLE mode operation of a UE. A UE enters, or is configured to enter, IDLE mode after a prolonged time of air interface inactivity. IDLE-mode DRX is also known as paging DRX, because the DRX duration can be understood as representing the time the mobile device can go to sleep between two paging messages that could contain a command for the UE to wake up again and change back to RRC_CONNECTED state. IDLE-mode DRX is much less fine grained and is measured in hundreds of milliseconds or even seconds.
A number of parameters control or otherwise relate to DRX. For example, “on-duration” is the duration in downlink subframes that a UE waits to receive PDCCH transmissions after waking up from DRX. If the UE successfully decodes a PDCCH, it stays awake and starts an inactivity timer. In turn, the inactivity timer defines the duration in downlink subframes that the UE waits to successfully decode a PDCCH, from the last successful decoding of a PDCCH. Failing any such successful decoding, the UE re-enters DRX. Further, the UE restarts the inactivity timer following a single successful decoding of a PDCCH, for a first transmission only—i.e., the inactivity timer is not restarted for retransmissions.
The “active time” is another DRX parameter of interest and it defines the total duration that a UE is awake over a DRX cycle. This awake or on-time represents the time during which the UE performs continuous reception while the inactivity timer has not expired and the time the UE performs continuous reception while waiting for a downlink retransmission after one HARQ Round Trip Time or RTT. Based on these details, the minimum active time is of a length equal to the on-duration, and the maximum active is undefined, i.e., infinite.
Of the above parameters the on duration and inactivity timer are of fixed lengths, while the active time is of varying lengths based on scheduling decisions and the failure or success of UE decoding. Only the on duration and the inactivity timer duration are signaled to the UE by the eNodeB. Further, only one DRX configuration is applied in the UE at any given time, and the UE applies the on duration upon waking up from a DRX sleep.
FIG. 5 illustrates DRX mode in the example case of LTE. As can be seen from FIG. 5, the UE activity time may be extended if PDCCH is received during the on-duration time of the UE. However, the activity time of the UE also may be shortened by the network sending a MAC DRX command to the UE, whereupon the UE stops the on-duration time and DRX inactivity timer. If the PDCCH is not successfully decoded during the on duration, the UE shall follow the DRX configuration—i.e., the UE can enter DRX sleep if allowed by the DRX configuration. This behavior also applies for the sub-frames where the UE has been allocated predefined resources.
If the UE successfully decodes a PDCCH for a first transmission, the UE shall stay awake and start the inactivity timer until a MAC control message tells the UE to re-enter DRX, or until the inactivity timer expires. This behavior holds even if a PDCCH is successfully decoded in sub-frames where the UE has also been allocated predefined resources, and in both cases the DRX cycle that the UE follows after re-entering DRX is given by the following rules.
First, if a short DRX cycle is configured, the UE first follows the short DRX cycle and after a longer period of inactivity, the UE follows the long DRX cycle. Note that the long DRX cycle will be a multiple of the short DRX cycle, if the short DRX cycle is used. If the short DRX cycle is not configured, the UE directly follows the long DRX cycle. Durations for long and short DRX cycles are configured by the RRC and the transitions between the short and long DRX cycles is determined by the UE based on the activity timer, or based on the eNodeB sending MAC commands to the UE. For example, if the MAC command is received and the short DRX cycle is configured, the UE will start or restart its short-cycle timer, drxShortCycleTimer, and use the short DRX cycle.
The network configures a number of parameters for DRX operation by a UE, such as the on-duration timer, referred to as onDurationTimer. The duration is specified in terms of the number of PDCCH subframes and may be any of: 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, and 200. The network can also configure the inactivity timer used by the UE, referred to as the DRX-InactivityTimer. The duration of this timer is also specified in terms of PDCCH subframes, and may be any one of: 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 500, 750, 1280, 1920, 2560. A specific value may also be configured if the UE supports In-Device Coexistence or IDC.
The network also may configure the long DRX cycle start offset, denoted as longDRX-CycleStartOffset. The value of this parameter depends on cycle length, but it is specified in terms of subframes and may have a value up to 2559. Conversely, the short cycle parameter, shortDRX-Cycle, specifies the duration of the short DRX cycle in terms of subframes and can have values of any of: 2, 5, 8, 10, 16, 20, 32, 40, 64, 80, 128, 160, 256, 320, 52, 640.
When a DRX cycle is configured, the active time of the UE includes the time while the onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimer or mac-ContentionResolutionTimer is running, or the time during which a Scheduling Request is sent on PUCCH and is pending, or the time during which an uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer, or a PDCCH indicating a new transmission addressed to the Cell Radio Network Temporary Identifier, C-RNTI, of the UE has not been received after successful reception of a Random Access Response for the preamble not selected by the UE.
Generally, new transmissions can only take place during the active time, so that when the UE is waiting for one retransmission only, it does not have to be “awake” during the RTT. When the UE is not in an active time, type-O-triggered Sounding Reference Signals, SRS, shall not be reported. Further, if CQI masking, cqi-Mask, is set up by upper layers, then, when the on-duration timer is not running, CQI/PMI/RI/PTI shall not be reported on the Physical Uplink Control Channel, PUCCH. Here, PMI denotes Precoding Matrix Indicator, RI denotes Rank Indicator, and PTI denotes Precoding Type Indicator. Thus, cqi-Mask effectively limits CQI/PMI/PTI/RI reporting to the on-duration period of the DRX cycle, and the same value applies for all serving cells of the UE. That is, the involved functionality is common across serving cells and not performed independently for each cell.
Among the several exceptions, however, regardless of whether a UE is monitoring PDCCH or not, the UE receives and transmits HARQ feedback and transmits type-1-triggered SRS when such transmissions are expected. Further, a UE may optionally choose not to send CQI/PMI/RUPTI reports on PUCCH and/or type-0-triggered SRS transmissions for up to four subframes following a PDCCH indicating a new uplink or downlink transmission, as received in subframe n-i, where n is the last subframe of the current active time window and i is an integer value from 0 to 3.
After the active time is stopped because of the reception of a PDCCH or a MAC control element, the UE may optionally choose to continue sending CQI/PMI/RI/PTI reports on PUCCH and/or SRS transmissions for up to four subframes. The choice not to send CQI/PMI/RI/PTI reports on PUCCH and/or type-O-triggered SRS transmissions is not applicable for subframes where the on-duration timer is running, nor is the choice applicable for subframes n-i to n.
As is recognized herein, there currently is no possibility for a network to control the network activity state of a receiving or target D2D UE, while accounting for the D2D activity of the UE.